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SYSTEM AND METHOD FOR NAVIGATING AND DELETING 

DESCRIPTORS 

BACKGROUND OF THE INVENTION 

This application claims the benefit of the earlier filing date of co-pending 
provisional application of Jon Ebbe Brelin and Hisato Shima entitled, ''System and 
Method for Accessing Navigating Descriptors/' Serial No. 09/541,145, filed March 31, 
2000 and incorporated herein by reference. 

Field of the Invention 

The present invention relates to data retrieval in audio, video or audio /video 
interconnected systems for home or office use and, more particularly, to a system 
and method for navigating a descriptor hierarchy within such systems. 

Background 

Data retrieval from a high speed serial bus such as an Institute of Electrical 
and Electronics Engineers (IEEE) 1394 standard serial bus, std 1394-1995, Standard 
For A High Performance Serial Bus, (August 30, 1996) (hereinafter referred to as the 
'TEEE 1394 standard serial bus") incorporates unnecessary operations and burdens 
an audio video /control ("AV/C") protocol that uses the IEEE 1394 standard serial 
bus. One illustration of this problem relates to the IEEE 1394 standard serial bus 
that uses a controller device to navigate a descriptor hierarchy in a target device 
(also referred to herein as a data structure hierarchy) and the controller sends a 
command to, for example, a descriptor to open. An AV/C controller ("controller") 
is a device at a serial bus node that sends AV/C commands to control a remote 
AV/C device. A target's descriptor ("target") has defined fields used for sharing 
device information and which may be modified by any device. When navigating a 
descriptor hierarchy, a controller, using conventional AV/C commands, opens and 
reads a descriptor on a target device containing information. This information may 
pertain, for example, to a destination file. 

Navigating a descriptor hierarchy involves a controller opening and reading 
descriptors that are arranged in a hierarchical format. Descriptors in a descriptor 
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hierarchy may be read in a forward or in a backward approach. A forward 
approach involves operdng and reading a descriptor to determine the next 
descriptor to open. A conventional backward approach generally involves the 
controller memorizing the descriptors it has opened, and reversing the forward 
5 navigation path. 

To navigate descriptors, the controller sends an OPEN DESCRIPTOR 
command with a descriptor„specifier data structure specifying a list. Entry 
descriptors within the list may contain information about the next hierarchical list 
such as its child list. Using the READ DESCRIPTOR command, an entry's child list 

10 identifier {i.e. child_list_ID) is then returned to the controller and the next list which 

is a level below may be opened. Generally, there are two conventional approaches 
to refer to an entry descriptor in a list when issuing commands. First, 
descriptor_specifier 20^6 i^^y be used to specify an entry descriptor by the identifier 
of its list {ie. list_ID) and then by its entry position. Second, another descriptor 

15 specifier such as descriptor_specifier 21^6 may be used to specify an entry descriptor 

by its root list identifier {i.e. root_list_ID), its list type {i.e. list_type), and then by its 
object identifier {i.e. object_ID). 

There are niimerous disadvantages to these conventional approaches. For 
example, some AV/C subunits on the IEEE 1394 standard serial bus are required to 

20 support specific entry descriptors by entry position. Other AV/ C subimits are 

required to support descriptors by an object identifier. Consequently, controllers 
bear the burden of supporting both types of access methods depending upon the 
target that it is controlling. 

Another disadvantage is that if a controller has access to the list identifier in 

25 which the entry exists, the controller is generally required to support specifying that 

entry by an entry position. Specifying the entry by an entry position can be 
problematic. For instance, a list generally contains a plurality of entries and if one of 
the middle entries is deleted, their positions shift. For the purpose of illustration, 
assume that a list contains five entries. If the third entry position, for example, is 

30 deleted, the fourth entry position and the fifth entry position move and become the 

new third and fourth entry positions. This causes a problem because invalid 
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information may be supplied to a target by a controller that contains the old entry 
position. 

Yet another disadvantage is that if an AV/C target uses the object identifier 
reference {i,e. a field in the entry that identifies the object for which the entry 
5 represents), the AV/C target may also specify an ambiguous entry since object 

identifiers are unique only within a particular list_type and there may be many lists 
in the target of the same Hst_type. This is also problematic since the list is already 
opened by a list identifier and the AV/C subimit then must support that same list 
with a redundant specification such as the list_type specification when using 

10 objectJD specification. 

Another conventional approach for specifying descriptors in a descriptor 
hierarchy relates to the data that identifies the lists and entries in the descriptor 
hierarchy for navigation purposes. Presently, if a controller navigates a descriptor 
hierarchy in order to view hierarchical data, the controller navigates in a forward 

15 direction. The controller reads a descriptor and determines if any root lists or child 

lists exist. The controller may then open those lists. However, these lists typically 
lack information about their parent descriptor. In order to recall the parent 
descriptor identifier, the controller must track the descriptors that it has navigated 
by storing the identifications ('TDs") of the parent entry and child list descriptors 

20 within the storage device of the controller. However, other controllers may modify 

the descriptor hierarchy in a target device at any time causing the first controller to 
have erroneous data. It is therefore desirable to have a system of navigating a 
descriptor hierarchy that eliminates the redimdancies, ambiguities, complexities and 
other disadvantages associated with the conventional approaches. 

25 In addition to navigating descriptor hierarchies, conventional systems lack a 

straightforward way of deleting descriptors in a hierarchy. For example, generally 
two subfunctions in the WRITE DESCRIPTOR command defined in the AV/C 
documentation may be used to delete descriptor data. However, these two 
subfunctions do not account for the hierarchical nature of the descriptor structure. 

30 For instance, if the childJistJD field in an entry is deleted using the WRITE 

DESCRIPTOR command, there is no indication in the command how the entry's 
child Jist should be deleted. It is therefore also desirable to have a system and 
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method in a descriptor hierarchy that defines how to delete descriptors under 
various conditions. 

SUMMARY OF THE I^AAENTION 
5 A method is disclosed for coupling a first device and a second device to a bus. 

Parent descriptor information blocks are placed into a descriptor hierarchy data 
structure for AV/C devices. The descriptor specifier specifies an entry by a list 
identifier and an object identifier. Additional features, embodiments, and benefits 
will be evident in view of the figures and detailed description presented herein. 

10 

BRIEF DESCRIPTION OF THE DRAWINGS 
The present invention is illustrated by way of example and not limited in the 
figures of the accompanying drawings, in which like references indicate similar 
elements and in which: 
15 Figure 1 is a block diagram of one embodiment for multimedia network 

including various consumer electronic devices coupled through a high speed serial 
bus; 

Figure 2 is a block diagram of one embodiment of a controller AV/C device 
and a target AV/C device with a descriptor hierarchy residing in the target node of 
20 the IEEE 1394 standard serial high speed serial bus; 

Figure 3 illustrates descriptor_specifier data structure used by controllers in 
AV/C descriptor commands and by targets in its descriptors; 

Figure 4 illustrates in one embodiment a descriptor hierarchy conceptual 
diagram; 

25 Figure 5 illustrates in one embodiment a parent descriptor info block for a 

child list that is to be placed in the list descriptor's extended information area; 

Figure 6 illustrates in one embodiment, a parent descriptor info block for a 
root list that would be placed in the root list descriptor's extended information area; 
Figure 7 illustrates in one embodiment the list descriptor that may include 
30 parent entry descriptors; 

Figure 8 is a flow diagram of one embodiment related to using the new 
descriptor specifier in a command to access a descriptor; 

4 
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Figure 9 is a flow diagram of one embodiment for embedding information 
about the parent entry or SID within the list descriptor for backwards navigability. 

Figure 10 illustrates in one embodiment of deleting a child list by deleting the 
child list in the descriptor specifier; 
5 Figure 11 illustrates a child list being deleted by deleting the parent entry 

descriptor in the descriptor_specifier; 

Figure 12 illustrates deleting a list and its child lists by deleting the list 
descriptor specified in the descriptor specifier; 

Figure 13 illustrates a root list being deleted; 
10 Figure 14 illustrates a new DELETE DESCRIPTOR command that may be 

used to delete various descriptors; 

Figure 15 illustrates a response frame of the DELETE DESCRIPTOR 
command; 

Figure 16 illustrates a descriptor being deleted when another descriptor in the 
15 descriptor hierarchy is open for a write operation and another descriptor is open for 

a read operation; and 

Figure 17 illustrates the descriptor hierarchy after descriptors in the 
descriptor hierarchy of Figure 16 have been deleted. 

20 DETAILED DESCRIPTION 

In one embodiment, a system is disclosed in which a device is coupled to 
another device that contains shared navigable information by a bus, such as a IEEE 
1394 standard serial bus. A type of descriptor specifier is introduced which specifies 
an entry by its list_ID and then its object_ID. In this system, descriptor navigation 

25 information is entirely contained within the descriptor hierarchy allowing for a 

direct route in a backward direction when navigating the data within the descriptor 
hierarchy. This reduces the burden caused by multiple controller storage of 
navigation data. 

In another embodiment, a parent descriptor information block is placed in 
30 both types of list descriptors. This allows a controller to navigate descriptors in a 
backward direction without having to store the list identifier of the list descriptors 
within the storage device of one or more controllers. 

5 
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In yet another embodiment, a DELETE DESCRIPTOR is used for cascade 
deleting descriptors in a descriptor hierarchy. 

In the following description, numerous specific details are set forth to provide 
a thorough understanding of the invention. However, it will be understood by one 
5 of ordinary skill in the art that the invention may be practiced without these specific 

details. In other instances, well known structures and techniques have not been 
shown in detail to avoid obscuring the invention. 

Figure 1 is a block diagram of one embodiment for multimedia network 100, 
including various consumer electronic devices coupled through a high speed serial 

10 bus 160. The high speed serial bus 160 may be, for example, an IEEE 1394 standard 

serial bus. In one embodiment, the multimedia network 100 may be located in one 
physical building, such as a home or an office. Multimedia network 100 may 
include digital video camera 110, digital video morutor 120, personal computer 130, 
palm pilot 135, digital video cassette recorder ("VCR") 140, and printer 145. High 

15 speed serial bus 160 supports communication of digital audio/video data and 

computer transmission data between the network devices. Digital video camera 110, 
digital VCR 140, printer 145, or any other consumer electronic device typically do 
not have direct Internet access whereas computer 130 and palm pilot 135 may be 
configured to have Internet access. Network 210 that includes networks such as an 

20 intranet or a global network such as the Internet, interfaces with computer 130 and 

palm pilot 135 through, for example, a telephone line (not shown) or wireless 
communication. 

Figure 2 is a block diagram of one embodiment of two AV/ C devices such as 
computer 130 and camera 100 shown in Figure 1 residing in two nodes of the IEEE 

25 1394 standard serial bus. System 400 includes controller device (also referred to 

herein as a second device) 410 connected to a target device (also referred to herein as 
a first device) 420. Target device 420 may be digital video camera ("DVC"). Target 
device 420 includes storage 430 such as memory for storing data and several 
descriptors (data structures) 405, 450, 460, and 470. Data may be tiransferred to and 

30 from descriptors 405, 450, 460, and 470. 
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Each descriptor 405, 450, 460, and 470 has a structured data interface 
containing information pertaining to features of device 420. A child descriptor is to 
the right of its parent descriptor, and a parent descriptor is to the left of its child 
descriptor. The identification of a child descriptor is maintained within the parent 
descriptor. For forward navigation, controller 410 accesses subunit identifier 
descriptor ("SID") 405. Controller 410 uses the known descriptor_specifier type "0" 
representing the SID 405. Using SID 405, controller 410 can open a root Ust 
descriptor 450. Thereafter, child Usts 460 and 470 (the child list is also referred to 
herein as the second list) can be opened by reading child_list_IDs in the parent 
entries in the root list 450. 

In one embodiment, list descriptors 450, 460, and 470 each include entry 
descriptors with objectJDs. This allows controller 410 to access a variety of 
information from a target device 420 by using a single descriptor specifier type, as 
shown in Figure 3, in a descriptor command such as a READ DESCRIPTOR. This 
descriptor specifier in a descriptor command specifies the list identifier and the 
object identifier for a imique entry descriptor. By including the list identifier and the 
object identifier, the descriptor command is used by controller 410 to access an entry. 
More specifically, controller 410 is able to open, read, or write the entry by 
specifying both the list identifier and the object identifer for that entry. 

The result of using a descriptor specifier with a list identifier and an object 
identifier {ie, listJD, object_ID) for an entry descriptor is that the descriptor 
specification is more precise which allows high speed serial bus 160 to be more 
efficient than typical high speed serial buses. For example, AV/ C subunits will no 
longer be required to support specifying descriptors by list„ID, entry_position 
and/ or support specifying descriptors by rootJistJD, list_type, or object_ID which 
can result in an unreliable or an ambiguous specification. Additionally, contrary to 
typical techniques, by using an entry descriptor that includes both a list identifier 
and an object identifier, if an entry position is dynamically changed, the entry 
position still maintains its uniqueness. The techniques of the invention eliminate the 
need of designating and supporting the ambiguous identifier 'Tist_type'' by 
maintaining both an object identifier and a list identifier in the same descriptor 
specifier. Furthermore, a descriptor specifier having a list identifier and an object 



080398.P310 

identifier is not ambiguous. Accordingly, less burden is placed on controller 410 
such as computer 130 compared to conventional techniques when the descriptor 
specifier having a list identifier and an object identifier is used as a return path for 
navigating descriptor hierarchies. 
5 Figure 4 illustrates one embodiment of navigating a descriptor hierarchy in a 

forward direction and a backward direction. Controller 410 is connected to target 
device 515 having a plurality of descriptors (405, 520, 540, 550, and 560). In this 
embodiment, a descriptor specifier having a list identifier and an object identifier is 
required. 

10 To navigate a descriptor hierarchy, backwards from, for example, a root list, 

refer to position 522. At position 522 of descriptor 520, the parent descriptor 
information block refers to SID 405 as its parent. While the root list is open, 
controller 410 reads parent descriptor information block 522 to determine that SID 
405 is the parent and root_list_ID is its list_ID. Additionally, child lists for 

15 descriptors 540, 550, and 560 may be opened by reading entries in the root list. 

There is a parent descriptor information block within descriptors 540, 550, 
and 560 that refer to the root list. For instance, parent descriptor information block 
542 for a child list of descriptor 540 refers to parent entry 1 528 of descriptor 520, 
parent descriptor information block 552 for a child list of descriptor 550 refers to 

20 parent entry 2 526 of descriptor 520, parent descriptor information block 562 for a 

child list of descriptor 560 refers to parent entry 3 524 of descriptor 520. While a 
child list is open, controller 410 reads a parent descriptor information block for the 
particular child list to determine which specific list and entry in the descriptor 
hierarchy is its parent. 

25 While navigating descriptors, controller 410 may use descriptors such as 

descriptors 520 and 540 and move in a backward direction following, for example, 
its original path of descriptors 540 to 520. Typical techniques allow controller 410 to 
move in a backward direction provided that controller 410 keeps track of the 
descriptor that controller 420 previously navigated. A controller tracks its original 

30 path by storing the list identifier and the parent entry identifier of the list descriptors 

within the memory of the controller. To avoid tracking the navigation of the 
descriptors, techniques of the invention embed information regarding a parent list 

8 
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(also referred to herein as the first list) within the list descriptor as shown in Figures 
5 through 7. This allows the controller to navigate the descriptors without storing 
the identifiers of the list entry descriptor and parent entry descriptors within the 
memory of controller 410. 

5 Figure 5 illustrates the parent descriptor information block 600 for a child list 

that may be placed in the child list descriptor's extended information area. More 
particularly, the parent descriptor information block is placed at position 810 in list 
descriptor 800 as in Figure 7 by a CREATE DESCRIPTOR command. Descriptor 
information block 600 also includes list identifier 650 and object identifier 660 which 

1 0 are used by the controller for accessing the parent entry. Fields such as 

compoxmdjength 610, info_block_type 620, primary_fields_length 630, and 
descriptor_specifier_type 640 are general info block fields of the parent descriptor 
info block 600. The parent descriptor info block 600 may be placed in the extended 
information field (i.e. extended_information field) 810 shown in Figure 7. 

15 Figure 6 illustrates in one embodiment, a parent descriptor info block 700 for 

a root list placed in the root list descriptor extended information. The parent 
descriptor inio block is placed at 810 of list descriptor 800 shown in Figure 7. Fields 
such as compoundjength 710, info_block_type 720, and primary_fields_length 730, 
are general info block fields of the parent descriptor info block 700. One 

20 embodiment embeds information about the parent Ust within the list descriptor. 

Figure 7 illustrates the descriptor 800 with the extended information field. 
This descriptor structure applies to both root Usts and child lists. When a controller 
moves backwards in a descriptor hierarchy, the controller can read information in 
the extended information field 810 to determine the descriptor_specifier for opening 

25 its parent entry or SID. Therefore, contiroller 410, using the descriptor_specifier and 

the parent descriptor 600, may navigate in a forward or a backward direction in the 
descriptor hierarchy without storing information about the locations of the 
descriptors that the controller previously visited. 

Figure 8 is a flow diagram of one embodiment for using the new specifier for 

30 accessing an enhy descriptor. At block 300, a controller issues an OPEN 

DESCRIPTOR command witii a descriptor_specifier specifying a descriptor by a list 
identifier {i.e. UstJD) and an object identifier {i.e. object_ID). At block 310, a target 

9 
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opens the descriptor. At block 320, the descriptor is read by the controller using the 
same descriptor_specifier. 

Figure 9 is a flow diagram of one embodiment for embedding information 
about the parent entry such as for a child list or SID such as for a root list within the 
5 list descriptor for the purposes of navigating descriptors in a backwards direction. 

At block 910, a descriptor specifier for the parent descriptor is placed at the end of 
the root list descriptor {e.g., extendedjnformation field) or the child list descriptor 
during a CREATE DESCRIPTOR command. The descriptor specifier may specify an 
entry by a list identifier and an object identifier. The root list has a beginning (also 

10 referred to herein as a first position) and an end (also referred to herein as a second 

position). The new descriptor specifier is placed in the second position for the root 
list. The child list also has a beginning position (referred to herein as a third 
position) and an end position (referred to herein as a fourth position). The 
descriptor specifier is placed in the fourth position of the child list. At block 920, the 

15 parent descriptor, located in the extended information field of the child list 

descriptor, is used to determine the descriptor specifier of its parent entry or the SID 
if the controller is currently reading a root list. At block 930, an OPEN 
DESCRIPTOR command is issued with the descriptor_specifier for opening its 
parent entry (or SID) by a controller. Thus, the controller navigates backward in the 

20 descriptor hierarchy. 

Figures 10-16 illustrate methods for deleting a child list descriptor in a 
descriptor hierarchy BY USING THE NEW delete descriptor command illustrated in 
Figure 14. Figure 10 illustrates one embodiment relating to deleting a child list by 
using the child list in the descriptor„specifier. At block 1000, a child list descriptor is 

25 deleted. At block 1020, a childJD is then deleted which is due to the child list 

descriptor at block 1000 being deleted. At block 1030, has„child_ID attribute is 
updated to reflect that the child ID field has been deleted. The has_child_ID 
attribute should be updated whenever the child_ID is deleted because the has_child 
attribute, prior to deletion, is set to "1" which implies the child„ID field exists. 

30 When the childJD field does not exist, the has_child_ID attribute should be set to 

"0". The value in the has_child_ID attribute indicates to another device such as a 
controller whether a child list exists. At block 1040, an entry_descriptor_length is 

10 
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updated to indicate that the entry_descriptor Jength is shorter after the child ID 
field has been deleted. At block 1050, a list.descriptorjength is updated to also 
reflect that the list_descriptor_length has been shortened to indicate that the child ID 
field has been deleted. It will be appreciated that the X represents a target descriptor 
5 in a descriptor_specifier. 

Figure 11 illustrates a child list being deleted by deleting the parent entry 
descriptor. At block 1110, a child list descriptor is first deleted by using the new 
DELETE DESCRIPTOR COMMAND illustrated in Figure 14. At block 1120, the 
parent entry descriptor is deleted. At block 1130, the no_of_entry_descriptors field 
10 is updated to reflect that there is one less entry descriptor in the list. At 1140, the 

list_descriptor_length is updated to reflect that the Ust_descriptor Jength has been 
shortened. 

U Figure 12 illustrates child lists being deleted by using the parent entry 

ai descriptor's list in the descriptor_specifier. At block 1210, a child list descriptor is 

^^il5 deleted. At block 1220, a second child list descriptor is deleted. At block 1230, a list 

descriptor, which is the target descriptor, is deleted. 
zl It will be appreciated that an AV/C subunit may only delete leaf lists. Leaf 

lists are those lists that exist at the lowest level of the hierarchy such as child list 
m descriptors (1210, 1220). This is due to leaf lists containing entry descriptors without 

y20 child lists. If a controller is to delete a particular list at a random location in the 

E5 hierarchy, a subunit shell is required to search for all available lists to delete that 

^ which exists under that list. Thereafter, starting from the first leaf list, the siibunit 

begins deleting. As the leaf lists are deleted, their parent lists become leaf Hsts and 

are then capable of being deleted. 
25 It will be appreciated that when a root list is deleted, each individual delete 

operation may involve one or more descriptors as illustrated at blocks 1210 and 1220 

of Figure 12. 

In Figure 13, at block 1310, a root list descriptor (which is also a leaf) is 
deleted by using the new DELETE DESCRIPTOR COMMAND illustrated in Figure 
30 14. At block 1320, the rootJistJD is deleted. At block 1330, the 

number_of_root_Ust_IDs field is updated to reflect the deletion of the root list ID 
field. At block 1340, the SIDJength is updated since the SID has shortened. 

11 
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Figure 14 illustrates the new DELETE DESCRIPTOR-control corximand that 
may be used to delete various descriptors as described herein. The 
descriptor_specifier can specify a root list, child list, or an entry in which each of 
these may be deleted. When deleting entries, the DELETE DESCRIPTOR command 
should be issued on a descriptor opened by an AV/C controller. The entry may 
then be deleted. 

When deleting lists such as a root list or a child list, the DELETE 
DESCRIPTOR command should be issued on a closed descriptor to prevent any 
access disruptions to other controllers. The result field describes the result of the 
delete operation. The result field is set to OO16 on input to show that the delete 
operation has occurred successfully. This value of the result field can change in the 
response frame as shown in Table 1. 

Table I - Value of Result Field. 



Value of result 


meaning 




The target descriptor and all its child lists 
(if any) were deleted successfully. 




The target descriptor and some of its child 
lists were not deleted. Inspect the fields 
below in the command to determine 
which ones and the node IDs of the 
controllers that opened them. 


All others 


Reserved {i.e., values are not presently 
defined at this time, but these values may 
be defined in the future.) 



The DELETE DESCRIPTOR command, when issued on a non-leaf descriptor, 
attempts a cascade delete process as described above. If any descriptors are open for 
a read operation, then those descriptors should be force closed using a typical close 
command and thereafter deleted. If all the descriptors in the hierarchy are deleted, 
then the target should return an ACCEPTED response frame that should be the 
same as the command frame. If any descriptor carmot be deleted either directly or 
indirectly because its descriptor or related descriptors are open for a write operation, 
the command should return a REJECTED response. The DELETE DESCRIPTOR 
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response frame is provided in Figure 15. The number„of_undeleted_descriptors 
fields are filled with the number of imdeleted list descriptors resulting from the 
DELETE DESCRIPTOR control command. The number of undeleted_descriptors 
fields do not contain information about entry descriptors. 
5 The length of each descriptor„specifier is known by each descriptor„specifier 

type. If a descriptor has multiple open entries, then each of the descriptor specifiers 
and nodeJDS should be returned. For descriptors that are not open and cannot be 
deleted because their parent or children lists are open, a node_ID of 00 OO^e should 
be returned to indicate that they are not open. The length of each opener_node_ID 

10 should be two, since node_IDs are always two bytes in length. 

Figure 16 illustrates descriptor hierarchy being deleted when one descriptor 
within a hierarchy is open for a write operation and one descriptor is open for a 
read. If the AV/C controller is unable to delete the opened_for„write descriptors, 
the AV/C controller may issue an open descriptor NOTIFY command for each open 

15 descriptor to be notified when the descriptor is finally closed. The AV/ C controller 

may then reissue the same DELETE DESCRIPTOR command. 

At block 1330, list 2 is open for a read operation. Consequently, list 2 at 1330 
is force closed. List descriptor 1340 is then deleted and the parent entry is updated. 
Descriptor 1350 is also deleted and the parent entry updated. Leaf list descriptors 

20 1370 and 1380 are not deleted because its parent entry inside list 1360 is access 

protected. However, root list descriptor 1330 is deleted and the parent entry 
updated to reflect the deletion of the root list. List descriptor 1360, which is open for 
a write operation, is also access protected and therefore it is not deleted. 
Additionally, root list descriptor 1320 keeps all the entries accept the entry with the 

25 deleted child list. Finally, SID 1310 is not deleted. This provides a final result of 

descriptors that remain in the descriptor hierarchy as shown in Figure 17. Figure 17 
illustrates that lists 1330, 1340, and 1350 have been deleted from the descriptor 
hierarchy after the cascade delete process. 

In the preceding detailed description, the invention is described with 

30 reference to specific embodiments thereof. It will, however, be evident that various 

modifications and changes may be made thereto without departing from the 
broader spirit and scope of the invention as set forth in the claims. The specification 
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and drawings are, accordingly, to be regarded in an illustrative rather than 
restrictive sense. 
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CLAIMS 

y/hat is claimed is: 

1 1/ A system comprising: 

2 c a bus; 

3 the bus is comiected to a first device and a second device; 

4 a data structure within a first device which has a hierarchy of descriptors 

5 containing at least a first list descriptor and a second list descriptor and at least one 

6 entry descriptor, each descriptor containing at least one data structure, and 

7 the second device using at least one data structure in a command. 

1 2. The system of claim 1, wherein one of the first list descriptor and the second 

2 list descriptor has information about a first list. 

1 3. The system of claim 1, wherein an unambiguous specification of a data 

2 structure is made. 

1 4. The system of claim 2, wherein the information about the first list is placed in 

2 a second list. 

1 5. The system of claim 4, wherein the second list has a beginning and an end; 

2 and 

3 the information is placed at the end of the second list. 

1 6. The system of claim 4, wherein the information from the first list is placed in 

2 the second list in an extended_information field. 

1 7. The system of claim 6, wherein the second device accesses the 

2 extendedjnf ormation field allowing the controller to move backwards in a 

3 hierarchy. 

1 ygf A method comprising: 

2 ^ coupling a first device and a second device to a bus; 
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3 placing into a data structure a descriptor specifier which specifies an entry by 

4 a list identifier and an object identifier. 

1 9. The method of claim 8, further comprising: 

2 opening a data structure by the first device; and 

3 reading at least one entry in the data structure by a second device. 

1 10. The method of claim 8, comprising: 

2 embedding information about a parent entry within a child list descriptor. 

1 \^ The method of embedding information about a root„list_ID within a root list 

2 descriptor, comprising: 

3 reading the extended information field by a controller. 

1 12. The method of claim 11, further comprising: 

2 accessing the extended_information field allowing the second device to move 

3 backwards in a data structure hierarchy. 

1 13. The method of claim 8, further comprising: 

2 placing the descriptor specifier in an extendedjnformation field. 

1 14. The method of claim 13, further comprising: 

2 reading the information from the extendedjnformation field. 

1 13; The method comprising: 

2 / using a descriptor specifier that specifies an entry by list_ID and objectJD. 

1 16. The method of claim 15, further comprising: 

2 opening the descriptor using the descriptor specifier. 

1 17, The method of claim 15, further comprising: 

2 embedding information about a parent entry within the descriptor specifier. 

1 18. The method of claim 15, further comprising: 

2 placing the information about the parent entry at an end of a child list. 
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The method of claim 17, further comprising: 

reading the information from an extendedjnformation field. 

The method of claim 19, further comprising: 

using a descriptor specifier for opening a corresponding a parent entry. 
A method comprising: 

using a descriptor having a field of a list descriptor ID and an object ID. 
The method of claim 21, further comprising: 

placing the parent descriptor info block in an extendedjnformation field. 
The method of claim 21, further comprising: 

accessing the extendedjnformation field allowing a controller to move 



3 backwards in the descriptor hierarchy. 

1 24. The method of claim 21, further comprising: 

2 embedding information about a parent entry within a list descriptor. 

1 25. The method of claim 21, further comprising: 

2 placing the information about the entry in a child list. 

1 A method comprising: 

2 embedding a parent descriptor info block within a list descriptor. 

1 27. The method of claim 26, further comprising: 

2 placing a descriptor specifier info block for the parent descriptor in one of a 

3 root list descriptor and a child list descriptor. 

1 28. The method of claim 27, wherein the root list has a first position and a second 

2 position; and 

3 the descriptor specifier is placed at the second position. 

1 29. The method of claim 27, wherein the child Ust has a third position and a 

2 fourth position; and 

17 
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3 the descriptor specifier is placed at the fourth position. 

1 30. The method of claim 27, further comprising: 

2 using a descriptor specifier in a descriptor command for opening a parent 

3 entry. 

1 31. The method of claim 30, further comprising: 

2 navigating descriptors in a descriptor hierarchy wherein navigating is in a 

3 backward direction. 

1 32. A method comprising: 

2 / using a delete descriptor connmand, the delete descriptor command is 

3 configured to delete one of a root list, a child list, and an entry. 

1 33. The method of claim 32, further comprising: 

2 deleting a child_ID in a descriptor hierarchy. 

1 34. The method of claim 33, further comprising: 

2 updating has_child_ID attributes, 

1 35. The method of claim 34, further comprising: 

2 updating entry_descriptor_length. 

1 36. The method of claim 35, further comprising: 

2 updating list_descriptor_length. 

1 37 The method of claim 32, further comprising: 

2 deleting a child list descriptor in a descriptor hierarchy. 

1 38. The method of claim 37, further comprising: 

2 deleting a parent entry descriptor. 

1 39. The method of claim 38, further comprising: 

2 updating no_of entry descriptors. 
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1 40. The method of claim 39, further comprising: 

2 updating a list_descriptor_length. 

1 41. The method of claim 40, further comprising: 

2 deleting a first child list descriptor in a descriptor hierarchy. 

1 42. The method of claim 41, further comprising: 

2 deleting a second child list descriptor. 

1 43. The method of claim 42, further comprising: 

2 deleting a list descriptor. 

1 44/ A system comprising: 

2 / a bus; 

3 the bus is connected to a first device and a second device; 

4 a data structure within a first device which has a hierarchy of descriptors 

5 containing a child list descriptor which is deleted by the second device, the second 

6 device uses a delete descriptor, the delete descriptor command is configured to 

7 delete one of a root list, a child list, and an entry.; 

8 the second device deletes a child_ID; and 

9 one of a has_child_ID attribute, an entry_descriptorJength, and the 
10 list_descriptor_length is updated. 
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ABSTRACT OF THE DISCLOSURE 
A system comprising at least two devices coupled to a bus wherein at least 
one device contains a descriptor hierarchy. A data structure has a descriptor 
specifier which specifies an entry by a list identifier and an object identifier. 
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